The invention relates to a method of making communication or information services via a telecommunication network available to service users. More particularly it relates to a method of providing interprocess communication between service providers and service users via a notification and synchronization entity that has access to service nodes via which service agents are executable.
A service can be implemented in a telecommunications network either directly in the switches or via a so-called intelligent-network architecture.
A direct implementation in the switches is in principle only suitable for networks with a small number of switches, because to be ubiquitous any new service logic has to be put into all of the switches of the network. For a network with a large number of switches such a task is time-consuming and inefficient. If the switches are from different vendors, this may even become impossible to realize.
The intelligent-network architecture was designed for a rapid deployment of services. The service logic therefore resides not in the switches but in so-called service control points (SCPs), which also contain service-specific data that allows the service providers to customize services. Switches enhanced with the capability of recognizing when it is necessary to communicate with an SCP in order to get instructions on how to proceed further with a call, are called service-switching points (SSPs).
The service logics are hence moved to a few centralized SCPs, thereby accelerating the deployment of new services because less network components are involved than in the case of direct implementation. It however requires new operation and management systems in order to introduce the service logics into the SCPs, to manage and customize them, and sometimes to set the required service triggers in the SSPs, such as recognizing the prefix of a service.
In the intelligent-network architecture only the communication between the SCPs and the SSPs is standardized but not the required operation and management systems. This lack of standardization leads to incompatible and vendor-specific SCP/SSP platforms. A rapid deployment of services is only possible within a single-vendor environment. Furthermore it is not possible to port a service logic written for a specific platform to another one, thus making it almost impossible to deploy and manage a service across multiple platforms.
In IP telephony the architecture does not require any voice switches, which is besides the use of IP as communication means for both signaling control information and voice signals the most important difference to legacy telephone networks like PSTN or ISDN. Voice signals are sent directly between the terminals, reusing the same IP routers infrastructure as for the exchange of signaling information. The most widespread IP telephony architecture is based on the ITU-T recommendation H.323. In this case the terminals are connected additionally to gatekeepers which only perform call control functions such as registration, access and admission control, address translation, etc. The gatekeepers have no voice-switching capabilities and hence can be implemented by means of conventional software servers. The signaling information may be either exchanged directly, i.e. the signaling information needed for the control of a telephony call is exchanged directly between the involved terminals, or with the gatekeeper-routed method in which case the terminals talk to their gatekeeper which has the control over the telephone call. The gatekeeper-routed method provides to a service provider a point via which it can access and control an IP telephone call. The gatekeeper thus enables the service provider to offer not only PSTN-like supplementary services like call forwarding or call completion, but also more advanced services by combining telephony with other information services, e.g. a stock alert service where the service user is alerted via a telephone call if the price of a certain stock crosses a certain limit. The architecture described above also applies for other protocols like IETF-SIP or -MGCP.
The IN architecture can also be applied to IP telephony. The gatekeepers are considered as SSPs, which means that they intercept the telephone calls and recognize when it is necessary to contact an SCP for further instructions on how to proceed with a call from an IN-point of view. The only difference between a gatekeeper and an authentic SSP is that the gatekeeper performs only call control whereas an authentic SSP performs both call control and voice switching. This IN-based architecture allows for telecommunication service providers to reuse their expensive SCP-based service infrastructure to offer supplementary services to IP telephony users. However it exhibits the disadvantage of the vendor-specific aspect of SCP platforms which hinder the rapid deployment and the portability of services. It also reduces the range of offerable supplementary services to the capability of the existing SCPs.
It is an object of the invention to provide an architecture for service deployment that is scalable in number of service users, service executions, services and service providers.
It is another object of the invention to provide an architecture for service deployment that circumvents the problem of vendor-specific implementation which restricts the implementation of new services and the deployment and portability of services and reduces the range of offerable supplementary services to the capabilities of existing service-control points.
It is another object of the invention to provide an architecture for service deployment that provides to a service provider an easy and efficient means for supplying new services into the network and modifying them.
It is another object of the invention to provide an architecture for service deployment that allows service subscribers to directly customize their service profiles.
It is another object of the invention to provide an architecture for service deployment that permits the addition and removal of service nodes to distribute load over multiple such nodes, requiring only a minimum configuration therefor.
It is another object of the invention to provide an architecture for service deployment that is more reliable because a failing service node can be easily replaced by another one.
The invention is directed to a method of making communication or information services via a telecommunication network available to service users. In accordance with the method, registrations for service offer references are received from agent initiators. These agent initiators may reside in service nodes where they have been preprogrammed to register for certain services under the respective service offer references. For these references even a wild card approach may be used which refers to more than one service at once.
Also from a service provider for a service a service offer notification comprising a service offer reference is received. This is done via a provider module that provides its input to a notification and subscription service entity, also called NaSS entity, where the service offer references are received. The NaSS entity is performing the function of a repository of information where the information is collected and may be accessed by other entities. It may also be seen as sort of marketplace where the service providers present their services which may be then accessed by others. There may be several service providers offering several services, each of which corresponds to a service offer notification.
Then, to those agent initiators who have registered themselves under the received service offer reference, the service offer notification can be forwarded, i.e. if there is a match between an offered service and a desired service, information about the service, being contained in the service offer notification, is delivered to the agent initiator who asked for that service. The service offer notification is usable for obtaining a service agent for the service. The service agent might even be contained directly in the service offer notification. The service offer notification might also contain a pointer to where the service agent can be found. The agent initiator can then download or access the service agent.
The above actions can be regarded as a xe2x80x9cpublish-subscribexe2x80x9d mechanism, wherein the notification corresponds to the publication and the registration corresponds to the subscription.
Once the service agent is activated in the service node, this agent may need additional information to be executed. This additional information may be user-specific or environment-specific or be of any other nature.
For obtaining this additional information as input, a second xe2x80x9cpublish-subscribexe2x80x9d-like mechanism is performed. Namely from the service agent are received registrations for service subscription references, which means that the service agent asks for input. From the service users service subscription notifications are received. The service subscription notifications comprise a service subscription reference, i.e. the name of the service for which the service user wants to subscribe. Once a match between the notified service subscription reference and the service subscription reference for which the service agent registered, is found, the service subscription notification can be delivered to the corresponding service agent, i.e., the service subscription notification is made available to those service agents who have registered themselves under the received service subscription reference. The service subscription notification is then usable as input for the service agent for the service. The service is then executable.
In other words, the service deployment architecture allows a service provider to send a service offer notification to the NaSS entity. The service offer notification comprises a service agent descriptor which has a service offer reference. Service nodes which have been preprogrammed to have an agent initiator and access to a set of core services, register at the NaSS entity for services under a desired service offer reference. If the desired service offer reference matches the sent service offer reference, the service agent descriptor is forwarded to the agent initiator of the service node where the agent descriptor""s content is examined as to whether the service node is able to support the corresponding service agent. If the service agent is supportable, the service agent is fetched from its source. This source could be the service provider, some other place or even the service agent descriptor.
Service users subscribe for services giving a subscription reference to the NaSS entity. Furthermore the service agent in the service node registers itself at the NaSS entity with a desired subscription reference. If those two references match, the subscription information is made available to the service agent. Thereby the service user can hand over information to the service agent of the service the user intends to use, e.g. for a call forwarding-on-no-reply service, the service user can give the time after which the forwarding shall be performed and the number to which the call shall then be forwarded.